Add rebased Aptos CRE common and loop support#1896
Conversation
|
📊 API Diff Results
|
📊 API Diff Results
|
0f8d364 to
618e65e
Compare
…dapters - Aptos service protos and LedgerVersion RPC - Loop relayer and relayerset Aptos adapters - Capability registry transmitter hex decode and tests - ViewPayloadFromCapability and capability_convert helpers - Solana proto regen guard for missing source - Generated mocks and types
- ClassifyWriteVmStatus for retryable/terminal/already-processed - WriteFailureClassification and known non-Move VM status handling - Tests for write_status normalization and edge cases
- Regenerate aptos and evm chain-capabilities client.pb.go - go.mod/go.sum updates for chainlink-protos and tooling
618e65e to
435e3f3
Compare
| TxStatus TransactionStatus | ||
| TxHash string | ||
| TxIdempotencyKey string | ||
| TransactionFee *uint64 |
| TxStatus tx_status = 1; | ||
| string tx_hash = 2; | ||
| string tx_idempotency_key = 3; | ||
| optional uint64 transaction_fee = 4; |
Summary
What changed
LedgerVersionsupport used by the Aptos read flowWhy
The Aptos local CRE stack needs the common Aptos loop/service surface from the earlier read-capability work, plus the shared compatibility pieces consumed by the write path. This PR keeps that layer narrow so downstream repos do not need to reach around
chainlink-common.Testing
go test ./pkg/types/chains/aptos ./pkg/loop/internal/relayer ./pkg/loop/internal/relayerset ./pkg/loop/internal/core/services/capability -count=1